deflake serve-body-leak: skip on ASAN where RSS-based leak detection is not meaningful#28301
Conversation
…is not meaningful
|
Updated 11:24 PM PT - Mar 19th, 2026
✅ @alii, your commit 02c24f6644d49d1965211b170466370032e49e88 passed in 🧪 To try this PR locally: bunx bun-pr 28301That installs a local version of the PR into your bun-28301 --bun |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughImported the ASAN environment flag into a memory-leak test and updated test registration to mark these cases as todo when ASAN is active; expanded the inline comment to state ASAN makes RSS-based memory-leak thresholds unreliable. Changes
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📝 Coding Plan
Comment |
|
Found 7 issues this PR may fix:
🤖 Generated with Claude Code |
There was a problem hiding this comment.
LGTM, straightforward test skip for ASAN where RSS-based leak detection is meaningless.
Extended reasoning...
Overview
This PR modifies a single test file (test/js/bun/http/serve-body-leak.test.ts) to skip RSS-based memory leak tests when running under ASAN builds. The change adds isASAN to the import from harness and appends || isASAN to the it.todoIf() condition.
Security risks
None. This is a test-only change that skips tests under a specific build configuration. No production code is modified.
Level of scrutiny
Minimal scrutiny needed. This is a standard test deflaking pattern — skipping tests whose methodology (RSS measurement) is incompatible with ASAN's memory overhead. The isASAN helper is already well-established in the test harness and used elsewhere in the codebase.
Other factors
The rationale is sound: ASAN adds 2-3x memory overhead making RSS thresholds meaningless, and ASAN already has its own built-in leak detection. The change is consistent with how other tests handle ASAN incompatibility in this repo.
|
Deflake complete — |
…, not LSan Bun CI runs with detect_leaks=0 so LSan is disabled. The actual reason to skip is that ASAN's 256MB quarantine + allocator metadata pushes RSS past the 512MB threshold even without leaks, and the 2x slowdown risks hitting the 40/60s timeout.
There was a problem hiding this comment.
LGTM — straightforward test deflake adding isASAN to the existing skip condition.
Extended reasoning...
Overview
This PR modifies a single test file (test/js/bun/http/serve-body-leak.test.ts) to skip RSS-based memory leak tests on ASAN builds. The change adds isASAN to the import and appends || isASAN to the existing it.todoIf(...) condition. A clarifying comment is also added.
Security risks
None. This is a test-only change that conditionally skips tests under ASAN. No production code, no auth paths, no user-facing behavior is affected.
Level of scrutiny
Low scrutiny is appropriate. This is a small, mechanical test deflake that follows the exact same pattern already used in this file (e.g., isFlaky && isWindows for conditional skipping). The rationale is sound: ASAN inflates RSS via its quarantine and metadata, making the end_memory ≤ 512MB threshold meaningless, and ASAN has its own built-in leak detection anyway.
Other factors
- CI passed on all platforms per the robobun comment.
- No outstanding reviewer comments or unresolved discussions.
- CodeRabbit found no actionable issues.
- The bug hunting system found no bugs.
- The change is consistent with how this repo handles ASAN-incompatible tests elsewhere.
…is not meaningful (oven-sh#28301) The serve-body-leak test sends 10k warmup + 10k test requests per test case (7 cases = 140k requests) with 512KB payloads. Under ASAN this causes timeouts and crashes because: - ASAN adds 2-3x memory overhead, making RSS measurements meaningless for leak detection - ASAN significantly slows execution, causing test timeouts (40s/60s limits) - The subprocess gets OOM-killed under the added memory pressure RSS-based memory leak detection is not meaningful under ASAN, which has its own built-in leak detection. Skip these tests on ASAN builds.
…tection is not meaningful" (oven-sh#28337) Reverts oven-sh#28301
…is not meaningful (oven-sh#28301) The serve-body-leak test sends 10k warmup + 10k test requests per test case (7 cases = 140k requests) with 512KB payloads. Under ASAN this causes timeouts and crashes because: - ASAN adds 2-3x memory overhead, making RSS measurements meaningless for leak detection - ASAN significantly slows execution, causing test timeouts (40s/60s limits) - The subprocess gets OOM-killed under the added memory pressure RSS-based memory leak detection is not meaningful under ASAN, which has its own built-in leak detection. Skip these tests on ASAN builds.
…tection is not meaningful" (oven-sh#28337) Reverts oven-sh#28301
The debian-13-x64-asan-test-bun failure on the previous CI run hit test/js/bun/http/serve-body-leak.test.ts, which is a well-documented ASAN-flaky memory-leak test (see PR #28301 and test/no-validate-leaksan.txt:274). This PR only touches src/install/lockfile/ and test/cli/install/ — nothing in the HTTP/Bun.serve path. Re-rolling once.
The serve-body-leak test sends 10k warmup + 10k test requests per test case (7 cases = 140k requests) with 512KB payloads. Under ASAN this causes timeouts and crashes because:
RSS-based memory leak detection is not meaningful under ASAN, which has its own built-in leak detection. Skip these tests on ASAN builds.